Techniques For Underwriting Insurance Policies Using Web-Centric Insurance Management System

ABSTRACT

A scalable, adaptable, modular, and web-centric Insurance Back-Office System (IBOS) for serving the needs of carriers, agencies, agents, and service providers in the insurance industry is disclosed. The IBOS provides a framework for allowing web-centric collaboration among agents, agencies, carriers, and service providers, using applications that manage applicants, cases, and policies in an efficient and secure manner. The IBOS infrastructure is designed to facilitate the creation of a new application, module, tool, or view in a simplified manner. The web-centric application includes a first module for creating a case and a second module for tracking the case after the case has been submitted to the carrier for consideration.

This application is a divisional of U.S. patent application Ser. No.10/670,995, filed Sep. 23, 2003, which claims priority from U.S.provisional patent application 60/504,539, filed Sep. 19, 2003. U.S.patent application Ser. No. 10/670,995 and U.S. provisional patentapplication 60/504,539 are both incorporated by reference.

BACKGROUND

Insurance is a complex field. The underwriting of an insurance contractbetween an applicant and an insurance carrier often involves a pluralityof participants, each of whom plays a well-defined role in the complexunderwriting process. To facilitate discussion, FIG. 1 depicts in asimplified diagram the various participants involved in a typicalinsurance sales and underwriting process. In FIG. 1 and the figuresherein, a life insurance contract for a natural person is employed as anexample. However, the information disclosed herein applies equally wellto other types of insurance contract and/or to other types of insurancecustomer, i.e., irrespective whether the customer is a natural person ora legal or physical entity such as a corporation, a building, etc.

In the life insurance industry alone, for example, there are currentlybetween 200,000 and 250,000 licensed agents. These agents, shown asagents 102, 104, and 106 in FIG. 1, perform many customer interfacefunctions. For example, agents may prospect for potential customers,provide information to potential customers about various insuranceproducts, and interact with the customers to initiate the underwritingprocess once the customers decide on one or more insurance products.

During the underwriting process, an agent may work with his customer,now an applicant, to obtain necessary information and/or biologicalspecimens, and may answer any questions that the applicant may haveabout the proposed insurance contract and/or the underwriting process.After the insurance contract is approved by the carrier and executed bythe applicant, it becomes a policy in force, and the applicant, now theinsured, may continue to interact with the agent to update his personalinformation from time to time, to make a claim against the policy,and/or to obtain any further information about the insurance policyand/or any other insurance offerings.

Generally speaking, an agent may work for or through one or moreagencies. Some agents may work for a single insurance agency (such as inthe case of agents 102 and 104 with respect to an agency 108). Theseexclusive relationships between agents 102 and 104 with respect toagency 108 are indicated by reference numbers 114 and 116 respectively.Other agents may work for multiple agencies, such as in the case of anagent 106 with respect to agencies 108, 110, and 112. Theserelationships between agent 106 and agencies 108, 110, and 112 areenumerated by reference numbers 118, 120, and 122, respectively. Anagent may chose to work with multiple agencies to broaden his productofferings since an agency typically represents only a limited number ofinsurance carriers.

During the insurance underwriting process, agencies may rely onthird-party service providers (124, 126 and 128 in FIG. 1) to performvarious tasks, such as to obtain a health history of an applicant, andto obtain blood pressure readings, blood samples and/or any othermetrics required to evaluate the insurance contract proposed. In theUnited States, the market for service providers is dominated by abouttwo dozen large service providers. Generally speaking, the orders forsuch service come primarily from the agencies although some may comefrom the insurance carriers. Examples of these relationships are shownby reference numbers 140, 142, 144, and 146. As before, an agency maywork with as many service providers as necessary to fulfill therequirements of an insurance contract and/or to fulfill its obligationsto the insurance carrier interested in insuring the applicant.Similarly, insurance carriers can work with as many service providers asdesired.

Insurance companies or insurance carriers 150, 152, and 154 representthe entities that evaluate a proposed insurance contract in view of theinformation gathered by the agent, his agency, and/or one or moreservice providers, and to decide on an applicable rate and/or insurancepolicy limit. There are hundreds of insurance carriers offering lifeinsurance products in the United States. Insurance carriers haverelationships (160, 162, 164, 166, 168, and 170) with service providers(e.g. 124, 126, and 128), since it is customary (but not absolutelyrequired) that insurance carriers pay for the services furnished by theservice providers irrespective whether the service orders originatedfrom the agencies (e.g., 108, 110, or 112) or from the insurancecarriers.

Generally speaking, insurance carriers work with agents throughagencies. Accordingly, an insurance carrier generally has a contractwith one or more insurance agencies, which contract governs therelationship between the insurance carrier and the insuranceagency(ies). These contractual relationships are enumerated in FIG. 1 byreference numbers 180, 182, 184, and 186. The contract may include termssuch as the insurance products an agency may sell, its geographicalterritory, the commissions payable to the agency for a successfully soldinsurance policy, and the like. Although insurance carriers rarely workdirectly with agents, it is customary that an insurance carrier notify astate's insurance department of the appointment of an agent, in effectinforming the state's regulatory agency about the agents representingits product lines before the public in that state.

From a contractual standpoint, the participants depicted in FIG. 1 dealwith one another at arm's length. In practical terms, many of theseparticipants in the insurance underwriting process work with otherparticipants in endless permutations. As will be discussed in connectionwith FIG. 2, this fact currently contributes to a huge amount of wastedand/or duplicate effort and inefficiency in the insurance underwritingand management process.

FIG. 2 shows in a simplified diagram a typical insurance underwritingcycle. The cycle starts with a customer 202 contacting an agent 204 torequest information about insurance. Agent 204 may have identifiedcustomer 202 through his contacts or via his prospecting program, orcustomer 202 may have been referred to agent 204 by an agency and/or aninsurance carrier. During this pre-sale period, agent 204 typicallyprovides insurance information to customer 202, answers any questionsthat may specifically apply to customer 202, and/or clarifies anyinformation to entice customer 202 to apply for insurance. Since agent204 earns a commission on each successfully completed insurance policy,agent 204 typically has a vested interest in getting customer 202 tofill out an application and in following up with other participants inthe underwriting process to ensure that the application timely maturesinto a valid insurance policy.

If the insurance product offered is of interest to customer 202,customer 202 fills out an application, generally in the form of aquestionnaire that is designed to solicit certain preliminaryinformation from the applicant. The information to be provided mayinclude the name of the applicant, his birth date, any governmental formof identification such as his driver license number and/or his socialsecurity number, his age, certain lifestyle data, superficial medicalhistory, and the like. Agent 204 then forwards the application to agency206, which is an agency representing the insurance product of theinsurance carrier that the applicant is interested in.

Generally speaking, agency 206 at this point takes in the application,performs certain administrative quality-control checks such as to ensurethat the submitting agent can in fact sell the insurance contractproposed, that all questions in the application have been filled out,that the application is properly signed. Once the preliminaryquality-control checks are completed, agency 206 then forwards theapplication to both service providers 208 and an insurance carrier 210.Typically, the service provider gets specific orders based on therequirements of the carrier that offers the applied for insurancecoverage.

The transmission of the application may be made using traditional paperand mailing methods, or may involve the electronic transmission oftext/images. After the application has been transmitted, agency 206continues to monitor the application progress to ensure that the serviceprovider(s) timely perform the requested services and that theapplication is timely acted upon by the insurance carrier once all theinformation required by the insurance carrier is obtained.

Service provider 208 may provide various administrative and/orparamedical services. For example, service provider 208 may obtain ahealth history (e.g., an Attending Physician Statement or APS) from theapplicant's physician to be forwarded to insurance carrier 210. Asanother example, service provider 208 may obtain blood and urine samplesfrom the applicant, and forward the samples to a laboratory 212 foranalysis. The results of the analysis by laboratory 212 may be sent backto service provider 208 for forwarding to insurance carrier 210, or,more likely, laboratory 212 may send such analysis directly to insurancecarrier 210.

After insurance carrier 210 collects all the requisite information fromagency 206, service provider(s) 208, laboratory(ies) 212, and any otherparticipants in the insurance underwriting process, insurance carrier210 may begin the risk assessment process to determine the probabilityof whether and when the proposed insured (i.e., the applicant) wouldlikely be making a claim. For life insurance contracts, this riskassessment generally relates to deciding the expected mortality of theapplicant in view of the information obtained. Once risk assessment iscompleted, insurance carrier 210 may then place the applicant in apremium class, which determines the cost of the proposed insurancecontract for the applicant given the applicant's own uniquecircumstances and the proposed insurance limit amount(s).

This premium and/or insurance limit information is transmitted to agency208 and in turn to agent 204 to be discussed with customer 202. Ifcustomer 202 approves, the customer may execute the insurance contractat that point. At this point, the executed insurance contract becomes anenforceable insurance policy, thereby completing the insuranceunderwriting process.

As can be appreciated from the foregoing, the insurance underwritingprocess is a complex process requiring information from and coordinationwith numerous participants in a predetermined sequence. For years, theinsurance industry has been underwriting millions of insurancecontracts, and has developed techniques for obtaining the necessaryinformation to converting a pending application into apremium-generating policy. However, it is observed by the inventorsherein that the current process for insurance underwriting is extremelyinefficient and time-consuming. At every step in the chain, there is asignificant amount of duplication of efforts and inefficiency.

As one example, agencies, service providers, and carriers often havetheir own proprietary software for processing and tracking cases (i.e.,applications). This is particularly true for independent agents and/orindependent agencies and/or service providers. Accordingly, theinformation transmitted from one participant to another often comes indisparate packages, and often needs to be re-transcribed or translatedat every step to simply accomplish data entry.

Additionally, the insurance carrier and/or service providers oftenreceive disparate information related to a case at different times. Asignificant amount of effort must be spent correlating received piecesof information, all belonging to different cases and arriving atdifferent times. Current industry practice employs the applicant's nameand/or date of birth and/or some form of government identification suchas an applicant's social security number for correlation. Yet, it is notunusual that one of the participants along the chain mis-transcribes aname, a birth date, and/or a social security number, giving rise toconfusion for other participants down the chain.

The lack of coordination gives rise to inefficiency. If a certain amountof time has passed and the insurance carrier still has not received, forexample, laboratory results pertaining to a particular applicant, thecustomary way to resolve the problem is for an insurance carrieremployee to call or email the agency in charge of the case, asking theagency to contact the responsible service provider to ask the serviceprovider to contact the laboratory and request that the laboratoryforward the laboratory analysis to that carrier. This manner of problemresolution of course requires that there be a human being at eachparticipant to handle the call and/or email and to manually resolve theproblem.

For service providers, there is no efficient way to receive serviceorders from different agencies and/or insurance carriers. Again,information from different agencies and/or insurance carriers must bere-transcribed for data entry into the service provider's own ordermanagement and tracking software. If an applicant has a specialrequirement (such as a female applicant requesting that her physicalexamination be conducted with a female nurse), such information mustoften be processed manually. Service providers also have difficultiesgetting status information regarding a particular case from the variouslaboratories. If a vial of blood sample breaks during transit, and theresult is not transmitted to the insurance carrier timely, the serviceprovider may not know until it receives a call from the agency, askingwhy the insurance carrier has not received the requisite test result.Under this paradigm, the aforementioned problem in correlatinginformation means that a service provider must not only devote humanresources to correlate data received from the various agencies but mustalso devote human resources to answer calls and/or emails from agents,agencies, and insurance carriers about the progress and/or statusinformation on service orders.

Agencies and agents are compensated when the underwriting processcompletes. Accordingly, agents and agencies are particularly anxious infinding out status data regarding a case, in determining whetheradditional information is needed to move a case along, whether thatinformation can be provided by the service provider, the applicant, orby the insurance carrier. Given the different participants involved,with each participant employing its own proprietary software to processand monitor cases, there is no easy way for agents and agencies thesedays to easily monitor the status information pertaining to a case as itmoves among the participants, particularly after the case has beenforwarded to the service providers and the insurance carrier. Moreimportantly, agents serve as the customer interface function, and theinability to quickly obtain status information in order to meaningfullyrespond to status inquiries from applicants significantly lowerscustomer satisfaction. In some cases, the applicant may be sufficientlyfrustrated about the delay and lack of information to terminate theprocess with an agent, opting to reapply for insurance with a differentagency that can underwrite the policy in a shorter amount of time. Insome cases, the applicant may simply quit the process entirely out offrustration.

Perhaps the most visible manifestation of the inefficiency of thecurrent underwriting process can be seen in the average and standarddeviation values for the time required to complete a typical lifeinsurance underwriting cycle. According to some industry sources, atypical life insurance contract underwriting cycle currently requiresover two months to complete. It is not unusual that some applicationstake as long as 180 days to complete. From an applicant perspective, thedelay is especially frustrating, especially since meaningful statusinformation is difficult to obtain from his agent. From the perspectivesof the agents and agencies, the delay means that they are getting paidlate for the work done months earlier. For insurance carriers, theinefficiency translates into additional cost in processing each proposedinsurance contract. The lengthy insurance underwriting cycle also delaythe point in time where an insurance carrier can deem a pendinginsurance contract a premium-earning policy.

In view of the foregoing, improved methods and arrangements forunderwriting and managing insurance policies among the variousparticipants are desired.

SUMMARY OF THE INVENTION

In one embodiment, a scalable, adaptable, modular, and web-centricInsurance Back-Office System (IBOS) for serving the needs of carriers,agencies, agents, and service providers in the insurance industry isdisclosed. The IBOS provides a framework for allowing web-centriccollaboration among agents, agencies, carriers, and service providers,using applications that manage applicants, cases, and policies in anefficient and secure manner. The IBOS infrastructure is designed tofacilitate the creation of a new application, module, tool, or view in asimplified manner.

These and other features of the present invention will be described inmore detail below in the detailed description of the invention and inconjunction with the following figures.

BRIEF DESCRIPTION OF THE DRAWING

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1 depicts in a simplified diagram the various participants involvedin a typical insurance sales and underwriting process.

FIG. 2 shows in a simplified diagram a typical insurance underwritingcycle.

FIG. 3 shows, in accordance with one embodiment, the IBOS architecturecomponents.

FIG. 4 shows an exemplary screenshot of a IBOS application, iDesktop™

FIG. 5 shows, in accordance with one embodiment of the presentinvention, one deployment configuration for iDesktop™

FIG. 6 shows, in accordance with one embodiment of the presentinvention, an alternative approach wherein each participant (agency,carrier, service provider) hosts its own business database.

FIG. 7 shows, in accordance with one embodiment of the presentinvention, the sequence for user login and authentication.

An exemplary login screen for iDesktop™ is shown in FIG. 8.

An exemplary home page for iDesktop™ is shown in FIG. 9.

FIG. 10 shows an exemplary page displayed when the user is employing theQuickView™ module.

FIG. 11 shows an exemplary QuickView™ page displaying the summary bycarrier view.

FIG. 12 shows an exemplary QuickView™ page displaying the policies listview, showing five policies per page.

FIG. 13 displays another exemplary policy list view after the user hasspecified in FIG. 12 that 20 policies are to be displayed per page.

FIG. 14 shows an exemplary policy details view, which represents themost detailed display pertaining to a policy.

FIG. 15 shows an exemplary screen that the user can invoke to add afollow-up task to the policy shown to the policy details view.

FIG. 16A shows, in accordance with one embodiment of the presentinvention, the tools available in the QuickView™ module.

FIG. 16B shows, in accordance with one embodiment of the presentinvention, the tools available in QuickCase™, in accordance with oneembodiment.

FIG. 17 shows, in accordance with one embodiment of the presentinvention, a workflow for underwriting a policy using iDesktop™

FIGS. 18-22 show, in accordance with embodiments of the presentinvention, various exemplary views of the Client Tool of the QuickCase™module.

FIGS. 23-27 show, in accordance with embodiments of the presentinvention, various exemplary views of the Client Tool of the QuickCase™module.

DETAILED DESCRIPTION

The present invention will now be described in detail with reference toa few preferred embodiments thereof as illustrated in the accompanyingdrawings. In the following description, numerous specific details areset forth in order to provide a thorough understanding of the presentinvention. It will be apparent, however, to one skilled in the art, thatthe present invention may be practiced without some or all of thesespecific details. In other instances, well known process steps and/orstructures have not been described in detail in order to notunnecessarily obscure the present invention.

In accordance with one aspect of the present invention, there isprovided a scalable, adaptable, modular, and web-centric InsuranceBack-Office System (IBOS) for serving the needs of carriers, agencies,agents, and service providers in the insurance industry. The IBOSprovides a framework for allowing web-centric collaboration amongagents, agencies, carriers, and service providers, using applicationsthat manage applicants, cases, and policies in an efficient and securemanner. To improve user-friendliness, the inventive IBOS leverages onthe familiar desktop visual metaphor even though the applicationsthemselves are provided over thin web clients.

To promote secure collaboration in the insurance underwriting andmanagement processes, user access to the IBOS is role-dependent. Inother words, the data, views, tools, modules, and applications availableto a user of the IBOS depend on the role of the user. To clarify, thereare currently two broad roles within the IBOS. It is contemplated,however, that as the product evolves, additional roles may also beimplemented, and IBOS is designed such that additional roles can beaccommodated easily.

Currently, a user is either an agent/producer (“agent”) or a casemanager. An agent is the person directly interfacing with the insurancebuying public, and who is compensated for his effort in selling theinsurance product to the public. A case manager, who may work for anagency, a service provider, or a carrier, is an administrative personnelresponsible for gathering and processing information to help a casemature into a policy and to manage a policy once in force. Within thesetwo broad categories of roles, the IBOS is also user-specific in thatthe identity of the user may also be employed to determine the set ofapplications/modules/tools (collectively “mechanisms”) and the data thathe has access to.

The role-based feature allows, for example, an agent using the IBOS toemploy role-appropriate mechanisms to view/manipulate data related toclients and/or cases/policies. Being also user-specific, the identity ofthat agent will be employed to ensure that that agent canview/manipulate data associated only with his clients and/orcases/policies but not to view/manipulate data associated with otheragents' clients and/or other agents' cases/policies.

Likewise, a case manager in an agency using the IBOS can employrole-appropriate mechanisms (which may be the same or different fromthose employed by the agents) to view/manipulate data related tocases/policies assigned to her for managing in that agency. Being alsouser-specific, the identity of that case manager will be employed toensure that that case manager can view/manipulate data associated onlywith the cases/policies for which she is responsible but not toview/manipulate data associated with cases/policies under the managementof other case managers in the same agency or in different agencies. Thesame feature applies for case managers in service providers or incarriers.

Within a case, the user identity and/or role also determines the datathat the user can view and/or edit. In other words, a user may haveaccess for viewing to only some data pertaining to a case but not otherdata based on his user identity and/or role. Likewise, a user may beable to view some data but not edit such data based on his user identityand/or role. As an example, a case manager at a service provider may beable to view selected data pertaining to a case (e.g., the phone numberof an applicant for contact purposes) but not others (e.g., the policylimit). As another example, a case manager at a carrier may be able toview certain data pertaining to a case (e.g., the agency in charge ofthe case) but not edit such information (e.g., cannot change the agencyname to another agency).

Thus, while all the IBOS users employ thin web clients (e.g., a browseron a desktop, laptop, or palmtop computer or a browser on aPDA/web-enabled phone) to access the IBOS applications, the appearanceof the IBOS to a user may change depending on his/her role, and the dataavailable for viewing and/or manipulation is also dependent on his/heridentity. This is one way that the IBOS promotes compliance with privacyprotection initiatives in the industry as well as with privacyprotection regulations such as the federally-mandated HIPAA (The HealthInsurance Portability and Accountability Act of 1996) or GLB (TheGramm-Leach-Bliley Act of 1999).

IBOS is also context-dependent. A context can be characterized by one ormore environmental factors that, in combination, sets the context ofoperation. For example, role, browser type, organization type (e.g.,carrier, agency, or service provider), and others all combine to definea context that in turn defines how the application behaves in terms ofthe modules/tools/views available and the data accessible to a user.

The IBOS is implemented by a multi-layer component architecture, witheach layer serving as a container for grouping the modular componentsassociated with the layer below it. In one embodiment, the IBOS isimplemented by a five-tier architecture: portal/container, webapplication, module, tool, and view. These IBOS architecture componentsare depicted in FIG. 3. At the highest level is the portal/containerlevel 302. Under portal/container level is the application level 304.Application level 304 includes one or more web-centric applications,some or all of which preferably adopt the web-centric desktop visualmetaphor provided by portal/container level 302.

With respect to portal/container level 302, the IBOS can be deployedeither as a portal hosted by a third-party hosting company or acontainer/framework for a set of applications, which container/frameworkis hosted by the company locally at the company's server. The companyrepresents an agency or a service provider or a carrier. The portalmodel may be an aggregator model or a private-label model.

The aggregator portal model is particularly well-suited to the needs ofindependent insurance agents who may work for multiple insuranceagencies. In this aggregator portal deployment model, a third-partyhosting company would host the applications, and agents may be able tologin via the internet to use the IBOS applications. For example, theagent may type in “http://login.iitcorporation.com/idesktop” on any webbrowser to access the login page for the iDesktop™ application hosted bythe third-party hosting company IIT (whose URL is atiitcorporation.com). Once the user is authenticated and the user'srole/identity is resolved, the role-appropriate mechanisms are thenprovided for viewing/manipulating of user-appropriate data. It iscontemplated that the agent may be charged a fee for such use, which maybe, for example, a one-time per case/policy fee or a set monthly fee(which may be scaled based on volume if desired).

The third-party hosting company may also host the IBOS applications fora particular company, in effect providing hosting services for aprivate-label version of the IBOS. This is the case, for example, agencyABC or service provider OPQ or carrier XYZ wishes to buy or lease aprivate label version of the IBOS applications so as to promote theirname brand to their users, and contracts with the third-party hostingcompany to host the set of private-label applications for agency ABC orservice provider OPQ or carrier XYZ.

In this portal private label model, an agent working for agency ABC maybe able may type in “http://login.abc.com/idesktop” on any web browser.The server at abc.com then redirects the user to the third-party hostingcompany's server in a manner transparent to the agent accessing the IBOSapplication iDesktop™. Once the user is authenticated and the user'srole/identity is resolved, the third party host company server may thenserve up a private label version of the IBOS application iDesktop™,which appears to the agent as if it is a IBOS application branded andtailor-made only for the ABC agency. This portal private label model iswell-suited to the needs of companies (agencies/serviceproviders/carriers) that may wish to provide private-label access forfree for their employees/independent contractors but do not wish toundertake the task of hosting the IBOS themselves. The companies in turncompensate the hosting company (e.g., IIT) for the hosting serviceand/or for the use of the applications.

The company (agency/service provider/carrier) may also lease or buy theIBOS directly for hosting on a server at their site. In this model, theIBOS acts as a container/framework for the leased or purchasedapplications. This is similar to the portal private label model exceptthat the IBOS (and thus the portal) is now hosted by the company itself.

Applications 304 are preferably implemented as web-centric applicationsthat employ the desktop visual metaphor for accessing modules 306.Leveraging on the user's familiarity with desktop interfaces, such asWindows XP™ by Microsoft Corporation of Redmond, Wash., an application304 may be structured so as to appear as a desktop to the user. FIG. 4shows, in accordance with one embodiment of the present invention, anexample of an IBOS application, iDesktop™, which allows the participantsto manage the insurance underwriting process. iDesktop™ functionalitieswill be discussed in details later herein.

In the desktop world, the user accesses the desktop applications byclicking on icons on a toolbar. In FIG. 4, there is a toolbar 402, onwhich an icon 404 is displayed, signaling that the web-centric IBOSapplication currently employed is iDesktop™. Icons 406, 408, 410, and412 represent the icons for activating the modules associated with theactive application iDesktop™. This is in keeping with the desktopmetaphor wherein the user clicks on the icons on the tool bar toactivate desktop applications (whereas in the IBOS world in which thedesktop is only a metaphor, clicking on the toolbar icons will activatethe modules).

Returning to FIG. 3, each application serves as a framework to furnishan infrastructure for plugging in modules. In addition to theaforementioned iDesktop™, other applications exist to serve differentinsurance management needs. For example, applications directed towarddata mining of policy/policyholder data, toward making the client andcase intake process more efficient through the use of telephonic orweb-based interviews, and the like, may also be accommodated.

The remaining of the disclosure will be made with reference to iDesktop™as an exemplary application. It should be kept in mind, however, thatthe invention applies to other applications of the IBOS as well. Ingeneral, each application 304 such as iDesktop™ includes a plurality ofmodules to serve different business logic needs. Generally speaking,each business module comprises a set of business logic functions orfeatures, implemented as tools, that maps closely to the entities beingmanaged.

To clarify, in the IBOS, data is associated with entities. In iDesktop™,for example, the business data can currently be broadly classified asbeing associated with one of four entities: client, case, policy, orservice order. It is contemplated, however, that other entities mayexist and the IBOS architecture can readily accommodate additionalentities, if additional entities are desired.

In terms of terminology, a client is either a prospective applicant forinsurance, an applicant for insurance, or the insured (i.e., policyholder) if the insurance contract is approved and executed. Throughoutits lifecycle, the prospective and in-force insurance contract isreferred to as a case. Thus, an application for insurance is a case, andso is a pending policy, and so is a policy in-force. A policy is a caseafter it has been accepted by a carrier for consideration. A policy maybe pending policy, which means that the carrier has deemed the casesubmitted to have enough minimum information to allow the carrier tobegin the process of data collection from the service providers andothers, of performing risk and premium analysis, and ultimately ofapproving or rejecting the case. Once the carrier has approved a pendingpolicy and after it is executed by the applicant (and perhaps after thepayment of the first premium payment), the pending policy is convertedinto a policy in force.

A service order is an order for service to a service provider from anagent, an agency, another service provider, or a carrier. An exampleservice order may involve, for example, an order for EFG Company to takeblood and urine specimens of an insurance applicant for analysis. Theclassification of all insurance related data as belonging to one ofthese four entities vastly simplifies the logic model and user model forimplementing and using the iDesktop™ application.

The application framework also includes infrastructure for securitycontrol, access control, authentication and verification (user-login),general administration and setup, and the like. It is preferable thateach application includes at least three modules: a user profile moduleto manage user profiles, a general administration module for handlingadministrative tasks pertaining to the application such as to manageuser accounts, and a business module for accomplishing certain tasksrelated to insurance underwriting or management. Although thisorganization makes applications easier to implement and navigate, it isnot absolutely necessary in all cases.

Modules are configured to be modular, allowing the application to bescalable. For example, iDesktop™ may have seven modules but not all willbe required at all times. In fact, modules can be purchasedincrementally as need arises. There is, for example, a QuickView™ modulefor enabling agents and their case managers in an agency to analyze,quantify, and process cases. A QuickCase™ module allows collaborationamong agent/agency/service provider/carrier during the underwritingprocess, up to the time the case is accepted by the carrier and becomesan enforceable policy.

Each module 306 implements a plurality of tools. In one sense, a modulemay be thought of as a container that provides an infrastructure forplugging in modular tools. Both tools and modules are reusablecomponents, allowing the creation of new modules and/or new applicationswithout requiring a complete rewrite of codes. In other words, certaintools and modules are reusable, and different tools may be grouped toform a new module, and different modules may be grouped to form a newapplication. Tools can be customized by users using preference settings.

Generally speaking, there are two types of tools: generic tools andentity-specific tools. A generic tools represents a tool that can existin more than one module and functions in a substantially similar mannerin each of the modules in which it is deployed. Examples of generictools, which will be discussed in details later herein in connectionwith the QuickView™ and QuickCase™ modules, are hotlist, followup,report and search. Entity-specific tools are tools specific to entities(of which there are four in the exemplary implementation of iDesktop™)Client tools and service order tools are examples of entity-specifictools in the QuickCase™ module.

Each tool 308 may have a plurality of views. Like tools and modules, theviews are implemented by code that is modular and also reusable. In mosttools, there may be found three views: summary, list, and details. Inthe case of QuickCase™, a summary view provides an agent with a summaryview of the cases he is handling, sorted by some broad criteria (e.g.,by carriers). The list view provides, for example, a list of all casesthe agent is currently handling. The detailed view provides, forexample, the most detailed presentation of data associated with a caseundergoing the underwriting process.

One important aspect of the invention is the consistency with which newfeatures/product offerings can be developed and user navigation can beaccomplished. By classifying all insurance-related data as belonging toone of the entities (e.g., the four entities of the present example:case, policy, client, or service order), tools can be easily developed.By organizing the architecture into a plurality of discrete architecturelevels (e.g., five levels as in the present example), with each levelrepresenting a container for bundling the modular components associatedwith the level below it (e.g., a tool is a container for bundlingmodular views, a module is a container for bundling the modular tools,an application is a container for bundling the modular modules, and aportal is a container for bundling modular applications), development ofnew features/product offerings is vastly simplified.

In many cases, the development of a new feature/product offeringcomprises deciding which architectural level the new feature/productoffering belongs to (e.g., a new application, a new module, a new toolor a new view). Once the appropriate architectural level is decided, newfeature/product offering may be formed by bundling existing modulararchitectural components. If existing modular architectural componentsdo not satisfy all the requirements of the new feature/product offering,new code may be written but only to the extent necessary to supplementthe existing bundle.

With regard to user navigation, user friendliness is enhanced byleveraging on the desktop metaphor as mentioned earlier. However,navigation is also made consistent in that in an application, usersexpect to be able to invoke modules by, for example, clicking on theicons in the toolbar as shown in FIG. 4. Within each module, the userwill see certain generic tools (e.g., followup, hotlist, search, report)that behave substantially similarly across modules and certainentity-specific module. In one embodiment, within each tool, the userwill be presented with certain views (e.g., summary, list, anddetailed). This paradigm repeats for all applications, modules, andtools in the BIOS.

Preferably, each module is implemented with a given set of menus andtools. In one embodiment of iDesktop™, all modules are implemented withthree menus (action, tool, and help), and two access tools (of whichsearch is one access tool and the other may be a hotlist or summary orthe like) on its home page. The action menu provides the user with theactions that can be taken with respect to the entities selected (e.g.,cases, policies, clients, or service orders). An example of an actionmay be send an email to all clients selected, or to group all selectedcases into a hotlist (note that hotlist is either an action, denotingthat a group of cases or policies is to be marked as high priority, or ahot list may be an access tool, causing the group previously designatedas a hotlist to be displayed).

The tool menu furnishes the user with all the generic andentity-specific tools available in the module. Help provides helpfulhints in using the particular module. The search tool, which is one ofthe access tools visible in the home page of the module, allowing theuser to search the entities (e.g., cases, policies, clients, or serviceorders) according to some predefined criteria. In QuickView™ forexample, an agent may search for all his cases that has a policy limitbetween $750,000 and $1,000,000. Summary, as mentioned before, displaysthe entities in accordance with some predefined criteria, depending onthe preference setting. For example, an agent may use the summary toolto view all cases summaries sorted by agencies, carriers, or serviceproviders.

To facilitate collaboration, certain data needs to be shared among theparticipants of the insurance underwriting/management process. Ingeneral, it is preferable that data be encrypted using a highly secureencryption technology (e.g., 128-bit encryption in one embodiment) andusing a secure connection technology such as secure socket layer or SSL,(see Internet Engineering Task Force at ietf.org).

In one embodiment, the business database (i.e., the database thatincludes data regarding clients and/or cases/policies) is hosted at acentral hub, and carriers, service providers, agencies, and agents mayaccess data at this central hub. This is the case shown in FIG. 5wherein there is shown, in accordance with one embodiment of the presentinvention, an iDesktop™ application 502 and 504 executing at serversassociated with an agency and a carrier respectively. There is alsoshown an IIT aggregator iDesktop™ portal 508, representing theaforementioned aggregator portal.

There is provided a data hub 510, which is responsible for hosting thebusiness database. Data hub 510 includes an integration server 512,which provides business-to-business (B2B) transaction processing.Integration server 512 may include a web application transactional webengine 520, a data translation engine 522, and a workflow engine 524.The transactional engine 520 sends data to and receives data fromiDesktop™ applications 502 and 504 to facilitate underwriting a caseand/or managing cases/policies. This same engine may also be responsiblefor sending and receiving data for business partners (carriers,agencies, and service providers), in effect acting as a middleman tofacilitate the data transfer among these partners. It is contemplatedthat a per-transaction or per-case fee may be charged for this middlemanservice, which may include services such as data translation and publicworkflow management (discussed below) and others. The transacted data isconsolidated in the hub's database, shown in FIG. 5 as relationaldatabase management system (RDBMS) 509.

The business data or meta data translation engine 522 translates dataand formats data as data is exchanged among agencies, carriers, andservice providers. This ensures that the receiving party can receivedata in the format that can be easily used and analyzed, therebyeliminating the need for manual transcribing. A business rules engine526 for managing business rules is shown. The workflow engine 524 indata hub 510 implements public workflows, i.e., workflows among theagents, agencies, service providers, and carriers. A workflow is abundle of data and subtasks executed in a predefined sequence. Anexemplary portion of such a public workflow may include sending an emailto notify the agency at the same time that the service provider sends aspecimens result to the carrier. The public workflows are handled by theworkflow engine at data hub 510 since data hub 510 serves as the hubthrough which data among the participants may flow and therefore is anatural place for implementing the public workflow logic.

Each iDesktop™ application 502, 504, and 508 may also include a privateworkflow engine (reference numbers 502 a, 504 a, and 508 a). Theseworkflows are deemed private since they involve data and tasks to betransmitted internally within the participant's organization. Anexemplary portion of such a private workflow may include sending anemail to both an agent and his case manager, informing both that anapplication from the agent's client has been examined and anothersignature is needed before the case can be forwarded to the carrier.

Note that in FIG. 5, each of iDesktop™ applications 502, 504, and 508 isshown interacting with its own web client (which may be through a wiredconnection as in the case of web client 502 a or a wireless connection,as in the case of web client 502 b). IIT hub 510 is also shown coupledto legacy systems, such as the service providers' own order processingsystem 527, the agency's own case management system 526, or thecarrier's own application underwriting system 525.

It is not necessary that the business database be consolidated at a hubdatabase, such as RDBMS 509 of FIG. 5. FIG. 6 shows, in accordance withone embodiment of the present invention, an alternative approach whereineach participant (agency, carrier, service provider) hosts its ownbusiness database. Thus, in addition to iDesktop™ 602 a and 604 a, eachof agency 602 and carrier 604 can use multiple databases: its owninternal or third party application or business database, and a databasecontaining data for collaboration. Using the module QuickView™ as anexample, agency 602 also manages an agency database 602 b and aQuickView™ database 602 c. Likewise, carrier 604 also manages a carrierdatabase 604 b and a QuickView™ database 604 c.

There is also shown a hub 610, with its own iDesktop™ application 610 a,IIT global general agency database 610 b (also known as IITGA), whichcontains data pertaining to the plurality of agencies that employ hub610 to collaborate with service providers and carriers. There is alsoshown a QuickView™ database 610 c associated with hub 610. Generallyspeaking, IIT hub refers to the central application and databaseemployed to enable data exchange among IIT network and insurancebusiness partners (such as carriers, agents, agencies, serviceproviders).

The collaboration data in databases 602 c and 604 c are synchronizedwith hub database 610 c using either IIT's data synchronizationtechnology or an industry-standard web services technology. With respectto the carrier-provided data, the data in QuickView™ database (e.g., 610c or 602 c) includes carrier-provided data pertaining to updates onapproved and currently pending policies. This carrier-provided data fromthe carrier is synchronized with IIT hub (610) to update the QuickView.™database 610 c. Once synchronized, IIT hub 610 then synchronizes thecarrier-provided data at the agencies (e.g., in QuickView™ database 602c) to enable the IIT general agency system (IITGA) 602 d to view thelatest carrier-provided data.

FIG. 6 also shows a GA-QV integration facility 602 e in agency 602.There are times when the carrier may have its own legacy or third-partysoftware for case/policy management, and the data provided by thecarrier may differ in format from that originally provided to thecarrier. Furthermore, the carrier may not even employ the case numberassigned by iDesktop™ GA-QV integration facility 602 e employs algorithmto match the pending policy provided by the carrier with the case beingtracked by iDesktop™ (using for example the applicant name, his address,his birth date, his governmental identification data, and/or the like).Once the match is made, a translation table may be generated to permitcorrelation between the case being tracked by iDesktop™ and the pendingpolicy tracked by the carrier.

Web clients 610 d, 602 f, and 604 d are also shown in communication withtheir respective iDesktop™ applications. Although only one web client isshown per application, it should be understood that each iDesktop™application can service any number of web clients, through a local areanetwork, a virtual private network, or through the Internet, or anyother data transmitting network.

Generally speaking, data translation may be performed at the targetserver (e.g., the server receiving data such as the server at thecarrier, agency, or service provider) or more preferably, datatranslation may be performed by the IIT hub 510 or 610.

As mentioned, iDesktop™ is one application that can be plugged into theinfrastructure provided by the IBOS. iDesktop™ allows geographicallydiverse agents, agencies, service providers and carriers to collaboratein a secure, web-centric environment using the familiar desktop metaphorin order to underwrite and manage insurance policies. It is notnecessary that all agents, agencies, service providers, and carriershave a business relationship with one another to employ iDesktop™.Diverse groups of participants can all employ iDesktop™, and sinceiDesktop™ is role-sensitive, context-sensitive, and user-specific, auser of iDesktop™ can only access data for which he is authorized toview and/or manipulate. Thus, the iDesktop™ application can be madeavailable to thousands of business partners, all working on millions ofcases in various permutations of working relationships. The role-based,context-based, and user-specific features mean that ownership foraccessing cases for viewing and/or manipulating data is well-defined foreach case and each business partner working on that case, and there isvirtually no risk of a data security compromise on any case.

Generally speaking, iDesktop™ can be employed by an independent agentwho is not exclusively associated with any agency, by an agent who isexclusive with an agency, by a case manager at an agency, by a casemanager at a carrier, or by a case manager at a service provider.

FIG. 7 shows, in accordance with one embodiment of the presentinvention, the sequence for user login and authentication. The user mayaccess the application iDesktop™ (702) by, for example, typing theappropriate URL into a browser. For example, the user may type in“https://iit.idxtop.com:9443” which brings up a login screen. Anexemplary login screen is shown in FIG. 8. In the log in screen, theuser may either (703) enter his id/password (704) if he is an existinguser or may choose to register if he is a new user (706). If he is a newuser, the registration process may require the user to identify his role(i.e., agent or case manager) (706 a), to choose a new userID and apassword (706 b), and to enter his personal data (706 c) such as name,address, email, government IDs, and the like. The user may also berequired to identify data related to the agency/agencies, carrier(s) andservice provider(s) which pertain to his work. Once the registration iscompleted, the user is taken back to the screen where he can enter hisuserID and password.

Once the userID and password are entered, the user (whether new orexisting) will be authenticated (712). In one embodiment, authenticationis performed using a user database that is separate from the businessdatabase. Technologies such as directory server (available from theaforementioned Microsoft Corporation or Sun Microsystems, Inc. ofMountain View, Calif.) may be employed during the authenticationprocess. For a new user, the authentication may involve checking withthe carrier and/or service provider and/or agency to ensure that theuser is authorized as represented by the user. Part of the checkingincludes ascertaining the business data (e.g., regarding entities suchas clients, polices, cases, and service orders) that the user is allowedto access based on his role and his agency/carrier affiliation.

If authentication is successful, the user will be presented with thehome page of iDesktop™, which is presented in the desktop metaphor asmentioned earlier. This is shown in FIG. 9. From this home page ofiDesktop™ (and indeed from any page from this point onward), the usermay then select the module to work on by clicking on the appropriateicon in the toolbar.

In the insurance underwriting and management process, two modules arecurrently employed. However, additional modules may be involved inadditional functionalities are desired. QuickCase™ is employedcollaboratively among agent, his agency, the service provider(s) and thecarrier to create a completed insurance application. Once theapplication is accepted by the carrier, it becomes a pending policy. Atthat point, QuickView™ may still be employed to search, view, andannotate the policies with follow-ups and QuickCase™ is still employedto facilitate collaboration if an action is needed from one of thebusiness partners (e.g., from the service providers) to turn the pendingpolicy into a policy in force.

In one exemplary implementation of iDesktop™, QuickView™ is the toolemployed by the business partners for collaboratively viewing,researching data and status, and annotating (with follow-ups) on thepending policies and the policies in-force. If a business partnerdiscovers that a pending policy requires action to be taken, theclient/case/service order tools in QuickCase™ is then invoked to allowthe business partners to work collaboratively.

QuickView™ may be employed to perform many tasks associated withmanaging policies. For example, an agent or a case manager may employQuickView™ to view data pertaining to policies and to annotate policieswith follow-up data if desired. As another example, the user (agent orcase manager) may also employ QuickView™ to create a hot list ofpolicies for special attention. As another example, the user may employQuickView™ to search/filter policies available to that user to come upwith a search result comprising policies selected in accordance withsome search criteria. As another example, the user may create reports onany of the views displayed or on the policies using appropriatereporting criteria.

In one embodiment, the following tools are available in the QuickView™module: policies tool, follow-ups tool, reports tool, hotlist tool, andsearch tool. Policies tool is employed to view policies. In the policytool, the following views are available: summary by agency view (allpolicies for the user organized by agencies), summary by carrier view(all policies for the user organized by carriers), policies view (listof policies for the user), policy details view (the most detailed viewavailable for a policy), policy follow-ups view (all policies earlierdesignated for follow-up tasks for the user) and policy hotlist view(all policies earlier designated as a hot list for special attention forthe user). Followup tool is employed to designate one or more selectedpolicies for a particular follow-up task (e.g., call at 3 PM on August12, email service provider to request a female nurse to examine thisapplicant, etc.) Reports tool is the report generating utility to createpolicy reports according to some report generation criteria, whichreports may be created in an electronic form or a printed form. Searchtool allows the user to search for an entity (case, policy, serviceorder, client) according to the search criteria entered

In the QuickView™ module, a page displayed preferably comprises of threemain parts: module menus (e.g., action, tools, and help), module tool infocus (e.g., policies tool), and search tool form. FIG. 10 shows anexemplary page displayed when the user is employing the QuickView™module. In FIG. 10, the search tool form is shown by reference 1002. Inthe case of FIG. 10, the module tool in focus is the policies tool,which shows the summary of cases (1018) by agencies view. The modulemenus action, tools, and help are shown by reference numbers 1004, 1006,and 1008 respectively. The summary-by-agencies view, summary-by-carriersview, policies list view, and hotlist views may be invoked by clickingon tabs 1010, 1012, 1014, and 1016 respectively.

Preferably, the aforementioned three-part organization stays consistentthroughout the various pages of the modules and across different modules(e.g., QuickCase) so as to reduce the learning curve for new users, torender navigation consistent, thereby promoting user-friendliness, andto render the implementation of new modules simple.

FIG. 11 shows an exemplary QuickView™ page displaying the summary bycarrier view (which is displayed by clicking on tab 1012). FIG. 12 showsan exemplary QuickView™ page displaying the policies list view (which isshown by clicking on tab 1016). The policies list view of FIG. 12further comprises an option 1202, which allows the user to choose thenumber of policies displayed per page, an option 1204, which allows theuser to manipulate icons to move between pages in the policies listview, and an option 1206, which allows the user to remember the viewcurrently displayed in the page as a search criteria in the search tool.The saved search criteria may be saved with a name, and may be recalledby name at a later time to allow the user to quickly access the datapreviously displayed. FIG. 13 displays another exemplary policy listview after the user has specified in FIG. 12, using option 1202, that 20policies are to be displayed per page.

FIG. 14 shows an exemplary policy details view, which represents themost detailed display pertaining to a policy. This view may be invokedby clicking on any policy displayed in any of the views displaying oneor more policies in a summarized format (e.g., any of the summary views,hotlist view, followup view, search result view, policies list view, andthe like). Clicking activates the hyperlink associated with the policysummary data, allowing the page showing the policy details to bedisplayed.

FIG. 15 shows an exemplary screen that the user can invoke to add afollow-up task to the policy shown to the policy details view. The usercan arrive at the display screen of FIG. 15 by selecting the follow-uptool 1402 in FIG. 14, for example.

As mentioned, iDesktop™ is user-specific. Accordingly, policies viewableby some agents may not be viewable by other agents and/or case managers.iDesktop™ is also role-specific. Accordingly, a case manager may nothave some of the views available to agents. For example, a case manageremployed with a specific agency would see only cases associated withthat agencies. In which case, instead of a summary by agencies view, thecase manager may be presented with a summary by agents view or summaryby service providers view or summary by carriers view for all the casesassigned to her to manage. As another example, a case manger employedwith a carrier would see only cases associated with that carrier. Inwhich case, instead of a summary by carriers view, the case manager maybe presented with a summary by agencies view or summary by serviceproviders view for all the cases assigned to her to manage. This is anexample of how the role-specific feature of the IBOS both improvesefficiency/user-friendliness and promotes data security andconfidentiality.

FIG. 16A shows, in accordance with one embodiment of the presentinvention, the tools available in the QuickView™ module 1600. As shownin FIG. 16A, there are four generic tools: search tool 1602, followuptool 1604, hotlist tool 1606, and report tool 1608. There is also anentity-specific tool, which is policies tool 1610. These have beendiscussed earlier herein.

FIG. 16B shows, in accordance with one embodiment of the presentinvention, the tools available in QuickCase™, in accordance with oneembodiment. QuickCase™ may include search tool 1652, reports tool 1654,follow-ups tool 1656, and hotlist tools 1658. As mentioned before, theseare generic tools and they function in a substantially similar manner astheir counterparts in other modules. In addition, there are threeentity-specific tools: client tool 1660, case tool 1662, and serviceorder tool 1664.

Client tool 1660 may be employed by the agent to obtain informationabout a client and build a client profile. With respect to the exemplaryworkflow of FIG. 17, the client tool may be employed in step 1702 toobtain at least certain preliminary data regarding the applicant forinsurance such as his name, his age, and superficial lifestyle data suchas whether he smokes or skydives. Case tool 1662 may be employed by theagent to begin filling out data regarding the insurance policy theclient wishes to purchase (1704 in FIG. 17). For example, the client mayindicate that he wishes to purchase term life insurance for 20 years,with a $1,000,000 limit. During the underwriting process, case tool 1662may also be employed to view and/or annotate the cases, much in the samemanner that policies tools may be employed for policies in QuickView™.

Once preliminary client and case data is obtained, the client may alsoemploy the QuickQuote™ tool (1706) to search among carriers forinsurance products that fit the requirements of the client and toprovide some preliminary premium quote and/or to provide alternativeproducts that may also be of interest to the client. At this point, theagent may associate the case to be underwritten with an agency, if suchassociation hasn't been done as a default (e.g., as in the case wherethe agent is an exclusive agent of an agency).

Suppose the client chooses one of the insurance companies to pursuefurther. In one embodiment, the case is then assigned with a unique casenumber in iDesktop™, which subsequently serves as the primarycorrelation key for correlating all communication and data from variousbusiness partners pertaining to this case. If a communication or data issent from one of the modules of iDesktop™ pertaining to a case, theunique case number is automatically sent along to allow the receivingserver to easily correlate all communication and data pertaining to acase. In this manner, the invention advantageously avoids the prior artproblem of trying to resolve communication and data pertaining to a casebased on data that may be erroneous or duplicative.

As mentioned, if a carrier employs a legacy systems that works only withthe carrier's own case number, the correlation algorithm may be employedto, for example, match the pending policy as sent back from the carrierwith the case being tracked in iDesktop™ (based on, e.g., a combinationof applicant name, birthdate, social security number, and the like).Once a match is found, a correlation table may track such mapping toallow the business partners to easily correlate communication and datapertaining to a case when collaborating using iDesktop™.

In step 1708, the agent or a clerk at the agency may employ the serviceorder tool 1664 to order services, such as blood or urine tests, fromservice provider (1710). Ordering service causes the service order toolto send the order, along with relevant data (e.g., contact informationfor the applicant) to the service provider(s). Furthermore, the agent orclerk at the agency may employ QuickCase™ to send data pertaining to thepartially completed case 1712 to the carrier (1714). Service provider1710 may also employ QuickCase™ to collaborate with sub-contractors(such as laboratories) to obtain analysis service for urine specimen,for example.

The service provider 1710 may also employ QuickCase™ to collaborate withthe carrier and/or other sub-contracting service providers to furnishthe required information to the carrier to allow the carrier to evaluatethe pending policy.

The agent, agency, and carrier may employ QuickView™ to monitor theprogress and status of the case. For example, a case manager at acarrier may employ QuickView™ to ascertain whether all data requiredfrom the agency has been received and whether all data required from theservice provider has been received timely at the carrier. Tools such asfollow-ups, reports, and hot lists may also be employed to manage cases.Likewise, a case manager at the agency and/or agent may employQuickView™ to track the progress of a case. For example, the agent maydesignate a case to be one in his hot list, and he may note that it hastaken abnormally long for the service provider to provide the urinespecimen analysis result to the carrier. The agent may then follow upwith the service provider by sending an email or by anotheralerting/communicating facility within QuickCase™ to request that theurine analysis result be sent as soon as possible.

When a business partner completes a business task with respect to a case(e.g., the agency sending a case to the carrier or to the serviceprovider, the service provider obtaining a urine sample and sending thesample to a laboratory for analysis, a carrier receiving a blood sampleresult from a laboratory or a service provider), that business partnerupdates status information for the case in iDesktop™. Thereafter,business partners authorized for viewing the case data may readilyobtain status/progress information pertaining to the case at any timeusing, for example, Quickview™.

Once all the required information is obtained from the service providersand agent/agency, the carrier 1714 may then either accept the pendingpolicy, which becomes a policy in force (1716) after execution by theapplicant or the carrier 1714 may reject the policy and employQuickView™ to inform the agent/agency of the rejection (1718).

FIGS. 18-22 show, in accordance with embodiments of the presentinvention, various exemplary views of the Client Tool of the QuickCase™module. In FIG. 18, the QuickCase™ module is activated by pressing onthe “book of business” icon 1800 in the tool bar. Notice how thenavigation options and visual presentation on the screen 1801 followsthe theme of the present example: 3 menus and two active tools. In thepresent example, the default QuickCase™ has an active Clients and SearchTool. The Clients tool views are shown by 1802. FIG. 19 shows a ClientsList view in the Clients Tool.

FIG. 20 shows the Clients Details View. The Client Profile Form is shownin 2002, and the user can press icon 2004 to get a print-formattedreport of client details. The user can also add client to list ofselected items for action (2206). By using one of detail tabs 2008, theuser can obtain/access addition data pertaining to the specific clientin focus.

FIG. 21 shows a Client Followup screen. The list of follow-ups for theclient is shown in 2102. The new/updated follow-up form is shown byreference 2104. The screen of FIG. 21 is accessed by selecting NewFollow-up tab 2106 shown.

FIG. 22 shows a Client Follow-Up List View. All clients with follow-upitems are shown in the list 2202. The user can navigate to follow-updetail screen by clicking on the Client name 2204 (since all data shownin iDesktop™ is hyperlinked). By selecting option 2206, the user canselect the entity displayed (e.g., client) for follow-up action such asprint report, add to hot-list, etc). The search tool form is shown byreference number 2208.

FIGS. 23-27 show, in accordance with embodiments of the presentinvention, various exemplary views of the Case Tool of the QuickCase™module.

As mentioned, agents may employ the Case Tool to create cases forexisting or new clients. A new case for a new client may require thegathering of certain data pertaining to the new client via the Clienttool first, in one embodiment. The Case tool has, in one embodiment,case summary, case list, and case detail view. As in other iDesktop™modules of the present example, there are provided search, follow-up,and hotlist tools.

The summary view is shown in FIG. 23. This is activated by the summaryview tab 2302. The customized drilldown GUI 2304 displays summary of alluser cases. The case search tool is again shown by reference number2306.

FIG. 24 shows the Case List view of the Case Tool. The user can choosethe number of cases to be displayed per page (2402), and can save (2404)the view as a search criteria to access later, if desired. The columns2406 are sortable using a preference setting for criteria or by settingoptions in a popup menu, for example. The case displayed can be selected(2408) for further action, if desired. The case search tool is againshown by reference number 2410.

FIG. 25 shows the Case Details View. The Case Profile Form is shown(2502). User can select option 2504 to get a print-formatted report ofthe case details. The user can add the case to the list of items (2506).Through detail tabs 2508, the user can access other data pertaining tothe case in focus.

FIG. 26 shows the Adding New Followup view of the Case Details View. TheNew Follow-up form is shown (2602). The view of FIG. 26 is accessed byselecting the New Follow-up tab 2604.

The Case follow-up view 2700 is shown in FIG. 27. All cases withfollow-up items are shown in the list 2702. The user can navigate tofollow-up detail screen by clicking on the Case reference number 2704(since all data shown in iDesktop™ is hyperlinked). By selecting option2706, the user can select the entity/entities displayed (e.g., client)for follow-up action such as print report, add to hot-list, etc). Thesearch tool form is shown by reference number 2708.

Since iDesktop™ is intended to be web-centric, security is an importantconcern. Security among participants is assured by leveraging on therole-based and context-based feature, enabling a user to only access thesubset of data he is authorized to access. Access control includesauthentication and validation while all data transfer is preferablyencrypted (e.g., 128-bit encryption) using a secure connection (such asSSL). To enhance security, the data related to user access (e.g., theuser data base) is separated from the business data, which can only beaccessed by the application server through a firewall, using a secureconnection. Once the user is authenticated using the access database,the user may employ the application(s) on the application server toaccess the business data. Both the access database and the businessdatabase may also be physically secured in a secure physical location(e.g., a vault).

In accordance with one embodiment of the present invention, there isprovided a view-state database or table for tracking the current statesof the views of various tools. The view-state database is preferablypersistent in that the user can log off and the view-state database willremember the states of the various views at log-off. When the user logsin again, the views associated with the various tools are restored. Asanother example, a user may switch among tools while using QuickView™ orQuickCase™. The view-state database tracks the states of the views ofthe various tools and if the user returns to the previous tool, the viewassociated with that tool that was displayed just prior to switching isrestored, along with all the data associated with that view. This isuseful for insurance agents who deal with constant interruptions fromdifferent clients and who may need to be able to switch among toolsoften.

As can be appreciated from the foregoing, collaboration using theweb-centric, collaborative IBOS and iDesktop™ application allowsinformation, status, progress and instructions pertaining to a case tobe efficiently manipulated, transmitted, tracked, and shared amongbusiness partners authorized to view and/or manipulate that case. Thissolves the problems in the prior art that arise when differentparticipants in the insurance process employs different software totrack, process, and transmit information pertaining to a case.

Further, the ability for the business partners to employ thecollaborative, web-centric IBOS and iDesktop™ application to communicateamong themselves to resolve problems (e.g., through emails,notifications or private messenger messages that tie to the unique casenumber) as well as the ability to easily view a case status and progressat any time renders the insurance underwriting and management processessubstantially more efficient.

The use of a single unique case number to track a case within iDesktop™as well as the ability to automatically associate insurance informationand instructions sent via iDesktop™ with the unique case number duringtransmission and receiving times substantially eliminate the problemsassociated with correlating communication and data to cases in the past.

Since the agent can now obtain progress and/or status data pertaining toa case at any given time from any web-enabled device, customer serviceis substantially improved. The agent can now respond to a customer'srequest for status with accurate information. The agent can also trackthe cases, and take action to speed up the conversion of a pendingpolicy to a policy in force (e.g., by sending a timely reminder email tothe right party to take the next step in the process), the invention cansubstantially reduce the amount of time required to underwrite a policy.

While this invention has been described in terms of several preferredembodiments, there are alterations, permutations, and equivalents whichfall within the scope of this invention. For example, although agentsare discussed as being either independent or working exclusively for anagency, the invention also applies to agents who work directly forcarriers without agency intervention, either on an independent basiswith multiple carriers or exclusively with a carrier. It should also benoted that there are many alternative ways of implementing the methodsand apparatuses of the present invention. It is therefore intended thatthe invention be interpreted as including all such alterations,permutations, and equivalents as fall within the true spirit and scopeof the present invention.

What is claimed is:
 1. A system for role-based collaboration amongdisparate participants, comprising: a plurality of client devicescorresponding to a plurality of participants; and at least onecentralized server communicatively coupled with the client devices, theserver comprising: a business database programmed to store sets ofbusiness data, each set of business data associated with a correspondingprocess; an applications database programmed to host a plurality ofapplications; a workflow database programmed to store a workflowassociated with each process, the workflow comprising a series ofsubtasks executed in a predefined sequence; and wherein the server isprogrammed to: provide access to an application from the applicationsdatabase to the plurality of participants based on each participant'sidentity and role, via each participant's corresponding client device;enable a first participant from the plurality of participants access tofunctions of the application and access to a first subset of the set ofbusiness data associated with the process via the application, based onthe first participant's identity, role, and association with theprocess; enable a second participant from the plurality of participantsto access, via the application, a second subset of the set of businessdata associated with the process based on the second participant'sidentity, role, and an association of the second participant with afirst subtask from the series of subtasks, wherein the second subset ofdata is associated with the first subtask and the second participant isresponsible for executing the first subtask; and in response to an eventassociated with the completion of the first subtask, send a notificationto the first participant and transition the process from the firstsubtask into a subsequent second subtask from the series of subtasks,wherein: a third participant from the plurality of participants isassociated with the second subtask and responsible for executing thesecond subtask, and the second subtask is executed independently of thefirst participant; and the notification enables the first participant tomonitor progress of the process even though the first participant is notresponsible for performing the first subtask or the second subtask. 2.The system of claim 1, further comprising: a participant access databaselogically separated from the business database, the participant accessdatabase storing participant profile information including participantidentity and role information; wherein the server is further programmedto authenticate the participants based on identity and role informationprovided during a login sequence and the profile information stored onthe participant access database.
 3. The system of claim 1, wherein theserver is further programmed to: prior to storing the set of businessdata, receive an initial set of input data associated with the process;assign a unique case identifier to the set of input data; and store theinput data along with the case identifier as the set of business data inthe business database.
 4. The system of claim 3, wherein the server isfurther programmed to: receive output data from the second participant;and update the business data based on the received output data.
 5. Thesystem of claim 1, wherein the first subset includes at least a portionof the second subset.
 6. The system of claim 1, wherein the firstparticipant is an agent, the first subtask comprises generating outputdata about a client of the agent and the event comprises providing theoutput data from the second participant to the third participant, andthe second subtask comprises analyzing the output data.
 7. The system ofclaim 6, wherein the second participant is a service provider thatgenerates the output data and the third participant is an insurancecarrier and wherein analyzing the output data comprises using the outputdata to assess a risk associated with the client.
 8. The system of claim7, wherein the agent is compensated for the conclusion of the processsolely based on an approval of the process by the insurance carrier, andwherein the insurance carrier approves the process based on the assessedrisk and an assessed premium.
 9. At least one non-transitory computerreadable-storage medium storing instructions that, when executed by atleast one processor, cause the at least one processor to: store sets ofbusiness data in a business database, each set of business dataassociated with a corresponding process; host a plurality ofapplications in an applications database; store a workflow associatedwith each process in a workflow database, the workflow comprising aseries of subtasks executed in a predefined sequence; provide access toan application from the applications database to the plurality ofparticipants based on each participant's identity and role, via eachparticipant's corresponding client device; enable a first participantfrom the plurality of participants access to functions of theapplication and access to a first subset of the set of business dataassociated with the process via the application, based on the firstparticipant's identity, role, and association with the process; enable asecond participant from the plurality of participants to access, via theapplication, a second subset of the set of business data associated withthe process based on the second participant's identity, role, and anassociation of the second participant with a first subtask from theseries of subtasks, wherein the second subset of data is associated withthe first subtask and the second participant is responsible forexecuting the first subtask; and in response to an event associated withthe completion of the first subtask, send a notification to the firstparticipant and transition the process from the first subtask into asubsequent second subtask from the series of subtasks, wherein: a thirdparticipant from the plurality of participants is associated with thesecond subtask and responsible for executing the second subtask, and thesecond subtask is executed independently of the first participant; andthe notification enables the first participant to monitor progress ofthe process even though the first participant is not responsible forperforming the first subtask or the second subtask.
 10. The at least onenon-transitory computer readable-storage medium system of claim 9,further comprising instructions that cause the at least one processorto: storing participant profile information in a participant accessdatabase logically separated from the business database, the participantprofile information including participant identity and role information;and authenticate the participants based on identity and role informationprovided during a login sequence and the profile information stored onthe participant access database.
 11. The at least one non-transitorycomputer readable-storage medium system of claim 9, further comprisinginstructions that cause the at least one processor to: prior to storing,receive an initial set of input data associated with the process; assigna unique case identifier to the set of input data; and store the inputdata along with the case identifier as the set of business data in thebusiness database.
 12. The at least one non-transitory computerreadable-storage medium system of claim 11, further comprisinginstructions that cause the at least one processor to: receive outputdata from the second participant; and update the business data based onthe received output data.
 13. The at least one non-transitory computerreadable-storage medium system of claim 9, wherein the first subsetincludes at least a portion of the second subset.
 14. The at least onenon-transitory computer readable-storage medium system of claim 9,wherein the first participant is an agent, the first subtask comprisesgenerating output data about a client of the agent and the eventcomprises providing the output data from the second participant to thethird participant, and the second subtask comprises analyzing the outputdata.
 15. The at least one non-transitory computer readable-storagemedium of claim 14, wherein the second participant is a service providerthat generates the output data and the third participant is an insurancecarrier and wherein analyzing the output data comprises using the outputdata to assess a risk associated with the client.
 16. The at least onenon-transitory computer readable-storage medium of claim 15, wherein theagent is compensated for the conclusion of the process solely based onan approval of the process by the insurance carrier, and wherein theinsurance carrier approves the process based on the assessed risk and anassessed premium.
 17. A method for role-based collaboration amongdisparate participants, comprising: storing, by a business database,sets of business data, each set of business data associated with acorresponding process; hosting, by an applications database, a pluralityof applications; storing, by a workflow database, a workflow associatedwith each process in, the workflow comprising a series of subtasksexecuted in a predefined sequence; providing, by a server, access to anapplication from the applications database to the plurality ofparticipants based on each participant's identity and role, via eachparticipant's corresponding client device; enabling, by the server, afirst participant from the plurality of participants access to functionsof the application and access to a first subset of the set of businessdata associated with the process via the application, based on the firstparticipant's identity, role, and association with the process;enabling, by the server a second participant from the plurality ofparticipants to access, via the application, a second subset of the setof business data associated with the process based on the secondparticipant's identity, role, and an association of the secondparticipant with a first subtask from the series of subtasks, whereinthe second subset of data is associated with the first subtask and thesecond participant is responsible for executing the first subtask; andin response to an event associated with the completion of the firstsubtask, sending, by the server, a notification to the first participantand transitioning, by the server, the process from the first subtaskinto a subsequent second subtask from the series of subtasks, wherein: athird participant from the plurality of participants is associated withthe second subtask and responsible for executing the second subtask, andthe second subtask is executed independently of the first participant;and the notification enables the first participant to monitor progressof the process even though the first participant is not responsible forperforming the first subtask or the second subtask.
 18. The method ofclaim 17, further comprising: storing, by a participant access database,participant profile information in a participant access databaselogically separated from the business database, the participant profileinformation including participant identity and role information; andauthenticating, by the server, the participants based on identity androle information provided during a login sequence and the profileinformation stored on the participant access database.
 19. The method ofclaim 17, further comprising: prior to storing, the server receiving aninitial set of input data associated with the process; assigning, by theserver, a unique case identifier to the set of input data; and storing,by the business database, the input data along with the case identifieras the set of business data.
 20. The method of claim 19, furthercomprising instructions that cause the at least one processor to:receive output data from the second participant; and update the businessdata based on the received output data.
 21. The method of claim 17,wherein the first subset includes at least a portion of the secondsubset.
 22. The method of claim 17, wherein the first participant is anagent, the first subtask comprises generating output data about a clientof the agent and the event comprises providing the output data from thesecond participant to the third participant, and the second subtaskcomprises analyzing the output data.
 23. The method of claim 22, whereinthe second participant is a service provider that generates the outputdata and the third participant is an insurance carrier and whereinanalyzing the output data comprises using the output data to assess arisk associated with the client.
 24. The method of claim 23, wherein theagent is compensated for the conclusion of the process solely based onan approval of the process by the insurance carrier, and wherein theinsurance carrier approves the process based on the assessed risk and anassessed premium.